As mentioned in the last article in this series, the Siebel upgrade process is split into 3 separate parts:

1. Upgrade the Non-Production Database (Development Database).
   1. Perform the Database Upgrade.
   2. Perform the Incremental Repository Merge and any bug fixes.
2. Upgrade the production database (Non-Development instances).

We previously covered the first part of the upgrade, which was performing the database upgrade. During the database upgrade process, the wizard consolidates the Siebel table structure to add columns based on the current version to the tables from the previous version. It also adds new tables and indexes to the database which are based on the new version. Custom tables and indexes are left untouched. This is done so that the next step in the upgrade process, which is to add and consolidate the Siebel repository objects, has the underlying database structure in place.

In this article we cover the following parts of the upgrade:

1. Running the Incremental Repository Merge.
2. Running the “Upgrade Custom Database Scheme” part of the database upgrade.

Pre-Merge Tasks

The following tasks need to be performed before starting the repository merge.

1. Back up the Database. This is absolutely critical. If for some reason the repository merge process fails, the database can be restored to the nearest point, which is its post-upgrade state.
2. Navigate to the <Siebel Tools>\Bin\enu folder and open tools.cfg as shown in the image below:

3. Ensure that the following parameters are set and defined as shown in the image below (click for larger version):
   1. EnableToolsConstraint = FALSE
   2. DockRepositoryName= Prior Customer Repository
   3. SymStrPrefix= X_

4. Check that the ConnectString parameter is set correctly as shown below:

Running the Siebel Repository Merge

Open the command prompt and navigate to the <Siebel_Tools>\Bin folder.

Execute the following command: “siebdev /editseeddata“.

The tools login window opens up.

Login as SADMIN to the Server and click OK to open Siebel tools.

Verify that the Repository opened is the Prior Customer Repository as shown above.

Navigate to the Tools Menu -> Upgrade -> Upgrade Application. The application upgrade screen will open up.

Make the following selections in the dialog box:

1. Prior Standard Repository = Prior v8.X Siebel Repository (Vanilla 8.0 Repository)
2. New Standard Repository = New Siebel Repository (Siebel 15 Repository)
3. Prior Customized Repository = Prior Customer Repository (Old customized Repository)
4. New Customized Repository = New Customer Repository (Merged Repository)

Once the selections are made click on Merge.

The Upgrade checklist window opens up.

Verify all the items, check them and click Continue.

This will start the repository merge process. The merge process takes roughly 9 hours to finish. Once the merge finishes, it is important to make a backup of the database again, before starting the next steps.

Post-Merge Tasks

Once the repository merge process completes there are additional steps which need to be performed prior to committing the changes to the database (Upgrade Custom Database Scheme).

Generate EIM Temporary Columns

In Siebel Tools, from the File menu, choose Open Repository, and then New Customer Repository.

Select “New Customer Repository” and Click on Open.

From the Tools menu, choose Upgrade, and then Generate EIM Processing Columns as shown below:

In the dialog box, click OK to generate Siebel Enterprise Integration Manager processing columns for custom mappings as shown below:

In the Object Explorer window, choose Repository and verify that the Comment field on the New Customer Repository shows UpgEimCol as shown below:

This indicates that the Siebel Enterprise Integration Manager temporary columns were created successfully.

Resolving Repository Conflicts

The repository merge compares repository object properties in the Prior Siebel Repository, Prior Customer Repository, and New Siebel Repository. When the value of an object property is different in all three repositories, an object property conflict exists. The merge process will invariably generate some conflicts and it is prudent to review them. It is possible that no conflict resolution is required.

In Siebel Tools, with the New Customer Repository Open, navigate to Screens -> Application Upgrader -> Application Upgrade Attribute List as shown below:

Right Click on the Attribute Differences Applet and choose Critical Conflicts as shown below:

Export the list to excel and review each of the objects highlighted as shown in the images below:

Identify the changes which need to be made. For example, a field in a business component may have been customized in the prior version, which now has an equivalent vanilla field. The merge process will disable the old field and try to use the new field. If there is no data in the old custom field or if it is not used anymore, then it would make sense to keep the upgraded configuration (Use Standard Value as resolution). However, if the field is used and has data in it, it might be prudent to override this change and use the previous configuration (Use Custom Value as resolution), which was the configuration from the pre-upgrade repository.

Please bear in mind that this is a time-consuming process, however it must be done to ensure that any custom objects which are absolutely necessary are kept in the new repository and not overwritten.

Once this exercise is complete, we need make the relevant changes in the repository as well. Navigate to Screens ->Application Upgrader -> Application Upgrade Attribute List and choose the critical conflicts as earlier. For each record where you wish to use the previous configuration, click the override checkbox.

Once all the records which need to be kept as the previous configuration have the override flag checked, we can move to the next part of the post-merge activities.

Running the Siebel Post-Merge Utilities

In Siebel Tools, from the Screens menu, choose Application Upgrader, and then Application Upgrade Object List as shown below:

In the Application Upgrades list, select the record of the merge as shown below:

In the Application Upgrades applet, right-click on the current record and select Launch Post Merge Utility from the pop-up menu.

Click Yes when prompted as shown below:

The post-merge utilities will start. If the post-merge utilities encounter a problem and exit before completion, then we need to fix the problems in the merged repository, and then rerun the utilities. The exact errors are reported in the logs and are fairly easy to identify.

Once the post merge utilities complete successfully and back up the database again. We can now move to the final part of the upgrade which is applying the new custom repository to the database.

Upgrading the Custom Database Schema (Upgphys)

The upgrade of the custom database schema is exactly like the first part of the database upgrade which was covered in the last article except for a change in one part. Follow the same steps as the last article, until prompted for the upgrade options as shown below:

This time, we need to choose “Upgrade Custom Database Schema (upgphys)” and click on Next. The rest of the steps remain the same. Once this step is complete the database upgrade for the development database is complete.

Development Activities

Upgrade projects are complex and extremely time-consuming. Once the development database is upgraded, the entire application needs to be tested thoroughly. Best practices dictate the following sequence:

1. Upgrade development instance.
2. Perform unit tests on the Development instance (Technical Resources). The focus primarily needs be on the following:
   1. UI elements. The upgrade has a nasty habit of messing up the layouts of the various UI elements, some of which are mentioned below:
      1. Applets: The alignment of labels are altered along with the field alignment which completely alters the look and feel.
      2. Views: New Child applets may get added. The view web template may get changed. Disabled applets may get re-enabled.
      3. Screens: Additional views may get added.
      4. Menus: Additional Menu items may get enabled.
   2. Business Objects and Components: While additional fields are not a problem, joins, MVL’s may change. These need to be carefully analyzed and fixed. These are typically identified by SQL errors when the application is launched.
   3. List of Values: These are extremely important for the application to run. In the last article in the series, we backed up the S_LST_OF_VAL table. We need to verify that all the values which were active prior to the upgrade are still active.
   4. Integration Objects and Components: These need to be re-synchronized to align with the new Business Components and Objects.
3. Upgrade the Test Instance (upgrade instructions are in the next article on upgrading non-development instances).
4. Perform end to end tests on the test instance (Technical Resources with limited end user participation): It is a nice idea to have an integrated test instance so that end to end tests can be run, even if they are basic in nature. This will make sure that there are no surprises when the UAT instance is upgraded and the system goes for the user acceptance testing.
5. Upgrade the UAT Instance (upgrade instructions are in the next article on upgrading non-development instances).
6. Perform the User Acceptance Testing. In an upgrade scenario, basic process tests are not sufficient. Ideally speaking, the user acceptance testing should cover the following:
   1. Regression tests performed by the users.
   2. All end to end scenarios tested by the users.
   3. All aspects of the application (Sales, Service, Marketing and any other enabled components) tested thoroughly by the user group.
   4. Integration tests completed by the IT teams and the users.
   5. Performance testing by automated scripts. This will help in fine-tuning the application components for the production environment.
7. Upgrade production.

The next article in the series covers the upgrade of the non-development instances.

References

1. Siebel Bookshelf